Core services platform for wireless voice, data and messaging network services

ABSTRACT

A system and method for managing wireless devices in a wireless network that performs operation comprising: receiving a diagnostic request to analyze a problem associated with a wireless device operating in the wireless network; retrieving contextual information associated with the wireless device from a database of the wireless network; determining at least one solution for the problem associated with the wireless device based on the contextual information; transmitting the at least one solution; and receiving a confirmation that the problem has been resolved.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/267,379 filed Oct. 6, 2011 which claims the benefit of priority forprior Provisional Patent Application No. 61/501,131, filed on Jun. 24,2011, the entire contents of which are incorporated herein by reference.

FIELD OF THE INVENTION

Embodiments of the invention relate to services provided to consumersand operators of wireless networks.

BACKGROUND

The continued evolution of wireless network technology allows consumerstoday to communicate with each other by voice, data and text messagingthrough highly sophisticated network architectures. A consumer can makea phone call, download data and send text messages using a singlewireless communication device, such as a smartphone. Typically, aconsumer would purchase a plan from a network operator and beconstrained by the rules defined in the plan for the duration of theplan period. For example, if the plan's policy does not allow roamingoutside of a predetermined region, the consumer would be unable to makeany calls from his smartphone once he leaves that region. The consumermay be unaware of the cause of the problem, and cannot easily find helpat a time when he cannot make phone calls. As another example, if theplan has a set quota for data usage and the consumer has reached apredetermined threshold (e.g., 90%) of that quota before the end of abilling cycle, the consumer's future data traffic can be throttled(e.g., the Quality of Service (QoS) is lowered) until the next billingcycle starts. With the conventional operator's system, a consumer cannoteasily monitor his data usage and cannot easily request his QoS bemaintained at the same level throughout a billing cycle. Thus, theconventional operator's system for managing usage, offers, pricing andpolicy is inflexible and cannot easily adapt to consumers' needs.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying drawings, in which likereferences indicate similar elements and in which:

FIG. 1 is a diagram of one embodiment of network architecture in which aCore Service Platform (CSP) system may operate.

FIG. 2 is a diagram of one embodiment of a deployment model for a CSPsystem.

FIG. 3 is a diagram of one embodiment of a mobile communication device.

FIG. 4 is a diagram of one embodiment of a computer system.

FIG. 5 is an overview of CSP system integration according to oneembodiment of the invention.

FIG. 6 is an overview with further details of CSP system integrationaccording to one embodiment of the invention.

FIG. 7 is an embodiment of integration between a CSP system and anoperator network.

FIG. 8 is an embodiment of network signal flow.

FIG. 9 is another embodiment of network signal flow.

FIG. 10 is an embodiment of integration between a CSP system and awireless communication device.

FIG. 11 is an embodiment of a display screen of a CSP device application(CDA) that shows a “My Account” feature.

FIG. 12 is an embodiment of a display screen of a CDA that shows a “Tella Friend” feature.

FIG. 13 is an embodiment of a display screen of a CDA that shows a“Diagnostic Help” feature.

FIG. 14 is an embodiment of a display screen of a CDA that shows a“Contextual Help” feature.

FIG. 15A is an embodiment of a display screen of a CDA that shows a“Usage Alert” feature.

FIG. 15B is an embodiment of a display screen of a CSP deviceapplication that shows a “Roaming Alert” feature.

FIG. 16 is an embodiment of a display screen of CSP operator Webapplications.

FIG. 17 is an embodiment of Custom Relationship Management (CRM)integration.

FIG. 18 is an embodiment of a process for publishing offer/policy from aCSP system to an operator.

FIG. 19 is an embodiment of provisioning/order entry integration.

FIG. 20 is an embodiment of a process for provisioning/order entryintegration.

FIG. 21 is an embodiment of billing integration.

FIG. 22 is an embodiment of reporting integration.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth.However, it is understood that embodiments of the invention may bepracticed without these specific details. In other instances, well-knowncircuits, structures and techniques have not been shown in detail inorder not to obscure the understanding of this description. It will beappreciated, however, by one skilled in the art, that the invention maybe practiced without such specific details. Those of ordinary skill inthe art, with the included descriptions, will be able to implementappropriate functionality without undue experimentation.

FIG. 1 is a block diagram illustrating an embodiment of a networksystem. In the embodiment shown, a cellular device 100 communicates withan operator network 110 through a base station 102 and a base stationcontroller 104. Cellular device 100 can be a cellular telephone, asmartphone with data transfer and messaging capability, a tabletcomputer, a personal digital assistant (PDA), a video-camera, a gamingdevice, a global positioning system (GPS), an e-Reader, aMachine-to-Machine (M2M) device (i.e., an application-specific telemetrydevice that collects data using sensors and transmits the data to adestination such as a server over a network), a hybrid device with acombination of any of the above functionalities, or any other wirelessmobile devices capable of sending and receiving voice, data and textmessages. Cellular device 100 communicates with operator network 110using wireless protocols, such as Bluetooth, IEEE 802.11-based wirelessprotocols (such as Wi-Fi), and the like. Cellular device 100 is used bya consumer (equivalently, a subscriber or a user). Operator network 110is a wireless cellular network that includes a voice network (e.g., aglobal system for mobile communications (GSM) network), a data network(e.g., a general packet radio service (GPRS) network), and a messagingnetwork (e.g., a short message service (SMS) network). It is understoodthat operator network 110 can include voice, data and messaging networksthat are different from the GSM network, GPRS network and SMS network.In the embodiment shown, the voice network is represented by a networkswitching subsystem 106, the data network is represented by a ServingGPRS Support Node (SGSN) 127, a Gateway GPRS Support Node (GGSN) 107,and the messaging network is represented by a messaging gateway 108. Itis understood that operator network 110 includes various other networkcomponents, which are omitted herein for simplicity of illustration.Operator network 110 allows a user of cellular device 100 to engage invoice, data and messaging communications with devices coupled tooperator network 110 through external networks (not shown).

In one embodiment, base station 102 includes a radio transmitter andreceiver for communicating with cellular devices (e.g., cellular device100), and a communications system for communicating with base stationcontroller 104. Base station controller 104 controls base station 102and enables communication with operator network 110. In variousembodiments, base station controller 104 can control any number of basestations.

Network switching subsystem 106 controls voice network switching,maintains a register of cellular device locations, and connects operatornetwork 110 with an external voice network, such as a public switchedtelephone network, a private voice telephony network, or any otherappropriate voice telephony network. In one embodiment, networkswitching subsystem 106 includes a mobile switching center (MSC) 111, ahome location register (HLR) 113, and a visitor location register (VLR)114. MSC 111 controls, sets up and releases a voice connection usingsignaling protocols such as signaling system No. 7 (SS7). In someembodiments, MSC 111 additionally tracks the time of a voice connectionfor the purposes of charging cellular devices, decrementing availableusage, tracking monetary balance, monitoring battery status, and otherpurposes. In one embodiment, operator network 110 may include any numberof MSCs. Each of these MSCs serves cellular devices within a networkarea, which may include one or more base stations and one or more basestation controllers. Some of the cellular devices may be registered touse this network area as their “home network,” and some of the othercellular devices may be registered to use other network areas as theirhome networks. HLR 113 maintains a list of cellular devices whose homenetwork is served by MSC 111. VLR 114 maintains a list of cellulardevices that have roamed into the area served by MSC 111. When acellular device leaves its home network (e.g., the network area servedby MSC 111), the VLR (“target VLR”) of the network (“target network”) towhich the device has roamed communicates with HLR 113 in the homenetwork of the device. When HLR 113 has confirmed to the target VLR thatit can allow the device to use the target network, the device is addedto the target VLR, and the MSC in the target network sets up thecommunication for the roaming cellular device.

SGSN 127 and GGSN 102 are two of the main components in the core datanetwork of operator network 110. SGSN 127 is responsible for thedelivery of data packets from and to the cellular devices within itsgeographical service area. The tasks of SGSN 127 include packet routingand transfer, mobility management (attach/detach and locationmanagement), logical link management, authentication and chargingfunctions. GGSN 107 controls data communications switching and connectsoperator network 110 with an external data network, such as a local areanetwork, a wide area network, a wired network, a wireless network, theInternet, a fiber network, a storage area network, or any otherappropriate networks. In some embodiments, GGSN 107 is one of the corecomponents in the core data network of operator network 110. Althoughnot shown in FIG. 1, the core data network of operator network 110 mayalso include various other network switching components. GGSN 107 servesas an interface between operator network 110 and external data networks,and translates data packets into the appropriate formats for the deviceson each side. In the embodiment shown, GGSN 107 also performs policy andcharging enforcement and control via the functionalities of: Policy andCharging Enforcement Function (PCEF) 122, Policy and Charging RulesFunction (PCRF) 123 and Online Charging System (OCS) 124. PCRF 123performs policy control and flow-based charging control. To that end,PCRF 123 authorizes Quality of Service (QoS) resources and operations,e.g., service redirection and other policy-based actions. Ultimately,PCRF 123 resembles a collection controller in that it collects thesubscriber's subscription data and allows PCEF 122 to enforce thepolicies and the charging. OCS 124 facilitates the online chargingprocess by collecting charging information about network resource usageconcurrently with that resource usage. OCS 124 also approvesauthorization for the network resource usage prior to the actualcommencement of that usage. The approval may be limited in terms of datavolume or in terms of duration. PCEF 122 performs policy enforcement,service data flow detection, and flow-based charging functionalities.The policy control indicated by the PCRF 123 is enforced by PCEF 122. Tothat end, the PCEF 122 will permit the service data flow to pass throughPCEF 122 only if there is a corresponding active Policy and ChargingControl (PCC) rule and if OCS 124 has authorized credit for the chargingkey used for online charging. Ultimately, PCEF 122 ensures that serviceis provided with the appropriate QoS and that the subscriber is chargedin accordance with the charging rate set for the subscriber.

Messaging gateway 108 provides short messages transit between cellulardevices and other communication devices. Messaging gateway 108 can be aShort Message Service Center (SMSC), a multi-media messaging center(MMSC), or a network node coupled to the SMSC or MMSC. Messaging gateway108 delivers text messages through operator network 110 to/from externalnetworks via standard protocols such as Short Message Peer-to-PeerProtocol (SMPP) or Universal Computer Protocol (UCP).

In some embodiments, operator network 110 is coupled to a hosted serviceplatform 120 via a Core Service Platform (CSP) network 170 and a numberof network nodes. Hosted service platform 120 serves as a servicemanagement platform for wireless communication devices such as cellulardevice 100. Hosted service platform 120 may include multiple datacenters in multiple geographical locations with each data centerincluding multiple server computers. Hosted service platform 120includes a number of CSP engines 122 that provide a suite of functionsto automate both the sales and support processes towards wireless users.Hosted service platform and CSP network 170, as well as software hostedthereon, form a CSP system. An overview of the CSP system will bedescribed below in connection with FIGS. 5 and 6.

CSP network 170 provides connections between the data centers in thehosted service platform 120 and operator network 110. In one embodiment,CSP network 170 includes a GGSN 171 that implements PCRF 173 and OCS174. Depending on the agreements between the operator/owner of operatornetwork 110 and operator/owner of CSP network 170, both sets of (PCRF123, OCS 124) and (PCRF 173, OCS 174) can be active at the same time orat different stages of service deployment. In some alternativeembodiments, CSP network 170 does not implement PCRF 173 and OCS 174.Instead, host service platform 120 collects subscription data, policyand charging information from operator network 110.

The network nodes between operator network 110 and CSP network 170 arerepresented in FIG. 1 as operator network node 130, network node A 131and network node B 132. These network nodes (130, 131 and 132) caninclude switches, routers, bridges, and other network components. Therecan be any number of network nodes between operator network 110 and CSPnetwork 170. In the embodiment shown, operator network node 130communicates with network node A 131 via an integrated connection, whileit communicates with network node B 132 via three separate connectionsfor voice, data and text messaging.

In some embodiments, an operator IT system 150 is coupled to operatornetwork 110 via operator network node 130. Operator IT system 150receives subscribers' data and usage from operator network 110, andprovides the functions of Customer Relationship Management (CRM)/care,provisioning/order entry, billing/mediation (or payments), andreporting/data warehouse (DWH) (or business intelligence). Operator ITsystem 150 also provides a user interface (such as a desktop interfaceor a Web interface) for a system administrator to monitor and managethese functions. In one embodiment, operator IT system 150 includes acontrol center that hosts CSP operator Web applications 154. CSPoperator Web applications 154 allow an operator to manage its marketingcampaign, offers (equivalently, rate plans), pricing, billing andcustomer care in an integrated environment. Functionality of CSPoperator Web applications 154 will be described later in further detailwith reference to FIG. 16.

In some embodiments, cellular device 100 stores and runs CSP deviceapplication (CDA) 140. CDA 140 displays alerts and notifications toconsumers in response to the consumers' current usage and condition,provides customized contextual offers in real time, and allows consumersto select and purchase wireless products and services from theirdevices. Moreover, using CDA 140, consumers can diagnose and solve theirown service questions and problems directly from their wireless device.For example, CDA 140 can query multiple sources, including cellulardevice 100 itself, to perform a diagnosis. Functionality of CDA 140 willbe described later in further detail with an example shown in FIGS.10-15.

FIG. 2 is a diagram illustrating an embodiment of a deployment model forthe CSP data centers. The CSP data centers can be a cloud-basedcomputing system. In the embodiment shown, two data centers (220 and230) are coupled to operator Internet Protocol (IP) network 210 via CSPnetwork 170 and a number of network nodes (e.g., routers). Data centers220 and 230 are part of hosted service platform 120 of FIG. 1. Datacenters 220 and 230 can be deployed at different locations and eachcenter includes multiple server computers. Some of the server computerscan serve as Web servers providing resources that can be accessed by theoperator and subscribers. Data centers 220 and 230 can be synchronizedin real time, and either data center can carry the full service demand.In one embodiment, dynamic IP routing is established (e.g., BorderGateway Protocol (BGP)) between operator IP network 210 and data centers220 and 230, such that failure of one path will allow for automaticrouting via the alternative path.

It is understood that hosted service platform 120 of FIG. 1 can includeany number of data centers in any geographical locations. Operator IPnetwork 210 can be part of the data network of operator network 110 ofFIG. 1. In the embodiment shown, operator IP network 210 interconnectsGGSN 107, messaging gateway 108 and the systems of CRM,provisioning/order entry, billing/mediation, and data warehouse (DWH) inoperator IT system 150 of FIG. 1. In one embodiment, operator IP network210 and CSP network 170 exchange provisioning/order entry data, chargingdata records (CDRs), reports via standard 3^(rd) Generation PartnershipProduct (3GPP) interfaces (Gx, Gy).

FIG. 3 is a block diagram illustrating an embodiment of a wirelesscommunication device 300 (e.g., cellular device 100 of FIG. 1). In oneembodiment, wireless communication device 300 is a smartphone. Inalternative embodiments, wireless communication device 300 can be acellular telephone, a tablet computer, a personal digital assistant(PDA), a video-camera, a gaming device, a global positioning system(GPS), an e-Reader, a Machine-to-Machine (M2M) device (i.e., anapplication-specific telemetry device that collects data using sensorsand transmits the data to a destination such as a server over anetwork), a hybrid device with a combination of any of the abovefunctionalities, or any other wireless mobile devices capable of sendingand receiving voice, data and text messages. In the embodiment shown,wireless communication device 300 includes a radio transmitter 302, aradio receiver 304, a processor 306, memory 310, a subscriber identitymodule (SIM) 312, and a display 314. In some embodiments, SIM 312 isoptional and the inclusion of SIM 312 is dependent on the networktechnology in use. Radio transmitter 302 and radio receiver 304communicate with a base station (e.g., base station 102 of FIG. 1) usingwireless radio communication protocols. In some embodiments, radiotransmitter 302 and/or radio receiver 304 communicate voice signals,data signals, text signals (e.g., SMS), configuration and/orregistration signals, or any other appropriate kinds of signals.Processor 306 executes instructions stored in memory 310 to control andperform the operations of wireless communication device 300. In someembodiments, memory 310 includes one or more of the following: read-onlymemory (ROM), flash memory, dynamic random access memory (DRAM), staticmemory and data storage device. Memory 310 can act as temporary and/orlong-term information storage for processor 306. In one embodiment,memory 310 stores CDA 140. In one embodiment, display 314 can serve as agraphical user interface (GUI) that displays images and data, such asthe screen displays of CDA 140. The displayed images and data can beretrieved from memory 310 or other local storage, or can be receivedthrough radio receiver 304 from a Web server (e.g., the Web servers inthe CSP data centers).

In one embodiment, SIM 312 is a removable module storing an identifyingnumber for wireless communication device 300 to identify the device tothe network. In various embodiments, SIM 312 stores an InternationalMobile Subscriber Identity (IMSI) number, an Integrated Circuit CardIdentifier (ICCID) number, a serial number, or any other appropriateidentifying number.

FIG. 4 is a block diagram illustrating an embodiment of a computersystem 400. In one embodiment, computer system 400 can be a servercomputer within hosted service platform 120 of FIG. 1. In anotherembodiment, computer system 400 can be a server computer within operatorIT system 150 of FIG. 1. It is understood that hosted service platform120 and operator IT system 150 can include any number of servercomputers. In the embodiment shown, computer system 400 includes aprocessor 412, memory 410, an I/O device 404, a network interface 402, adisplay 414 and a bus 408. In one embodiment, display 414 can serve as agraphical user interface (GUI) that displays graphics and data to anoperator. Some of the displayed graphics and data can be retrieved frommemory 410 or other local storage, or received through network interface402 from a Web server. Processor 412 represents one or moregeneral-purpose processing devices. Memory 410 includes one or more ofthe following: read-only memory (ROM), flash memory, dynamic randomaccess memory (DRAM), static memory and data storage device. Networkinterface 402 communicates with an external data network. In anembodiment where computer system 400 is a server computer within hostedservice platform 120 of FIG. 1, memory 410 stores software implementingone or more of the functions of CSP engines 122, PCRF 173 and/or OCS174. In another embodiment where computer system 400 is a servercomputer within operator IT system 150 of FIG. 1, memory 310 storessoftware implementing one or more of the functions of CSP operator webapplications 154.

FIG. 5 is a block diagram illustrating an overview of CSP systemintegration according to one embodiment of the invention. FIG. 6illustrates further details of CSP system integration according to oneembodiment of the invention. In the following description, the term “CSPsystem” 530 refers to the software and hardware infrastructure thatmanages a suite of services provided to network operators and theirsubscribers. Thus, referring also to the embodiment shown in FIG. 1, CSPsystem 530 includes hosted service platform 120, CSP network 170, andthe software hosted thereon. CSP system 530 interacts with operatornetwork 110, operator IT system 150, and cellular device 100 in realtime. In some embodiments, CSP system 530 can also interact withoperator network 110, operator IT system 150, and cellular device 100 inbatch mode. In one embodiment, CSP system 530 is a smartphone servicemanagement platform. Through CDA 140 and CSP operator Web applications154, CSP system 530 provides or enables the functions of on-deviceapplication, self-care, diagnostics, store-front, alert management,policy control, payment handling, offer management, campaign management,analytics, reporting engine, and data rating.

Referring to FIG. 6, CSP system 530 provides customized contextualoffers based on contextual assessments of a consumer's current“context.” Such “context” includes, but is not limited to, time incontract, loyalty status, data and voice usage, value (or valuation) ofcustomer, time (of a latest data request), location (of a latest datarequest) and purchase history. The contextual assessments can be made byCSP engines 122, which run on hosted service platform 120 of FIG. 1 andperform the functions that include, but are not limited to, customerprofiling, micro-segmentation, real-time rating and policy, real-timealerts and offers, and targeted recommendations for offers andpromotions. CSP system 530 is able to not only identify who the consumeris, but also the consumer's current context, in order to make the rightoffers at the right time. CSP system 530 formulates offers that theconsumer is most likely to purchase and that are most valuable to theoperator. The consumer can choose one of the offers and make thepurchase from his device at the moment he most likely needs it tomaintain his usage level. For example, if the consumer is in the middleof downloading a video to his smartphone and his data usage limit orthreshold is reached, he can receive an alert on his smartphone withoffers to add more megabytes of data to extend his usage limit. In onescenario where the consumer's usage limit or threshold has not beenreached, he can also receive an offer to add more megabytes of data toimprove the download speed. The consumer can make the purchase from thissmartphone and continue the downloading with no or little noticeableinterruption. In one embodiment, the offers can include top-up offers orplan changes, which add more megabytes of data or more usage time to aconsumer's existing plan for the current billing cycle, or upgrades,which change the consumer's existing plan to a new plan that is notlimited to the current billing cycle.

Consumers experience CSP system 530 through CDA 140 on their wirelesscommunication devices. CDA 140 provides consumer-side functions thatinclude, but are not limited to: storefront, payment, offers and alerts,self-support, account status, and device diagnostics. Operatorsexperience CSP system 530 through CSP operator Web applications 154. CSPoperator Web applications 154 provide operator-side functions thatinclude, but are not limited to: offer and policy management, campaignand alert management, business and eligibility rules management, productcatalog, customer relationship management, merchandising and contentmanagement, campaign analytics, retail store activation, customer careapplication, and reporting. For the operator, this CSP experiencetranslates to the following three main benefits: (1) CSP system 530provides a retail store on every wireless communication device, therebyincreasing Average Revenue per User (ARPU) through real-time contextualselling; (2) CSP system 530 drives support cost towards zero byproviding a self-support experience for consumers; and (3) CSP system530 drives cost of sales towards zero using dedicated on-devicechannels.

In order to provide these benefits and reduce time to market, CSP system530 integrates with four functions of operator IT system 150. The fourfunctions are: CRM/care 610, provisioning/order entry 620,billing/payments 630 and reporting/DWH 640. CSP system 530 alsointegrates with two functions of operator network 110. The two functionsare GGSN 107/PCEF 122 (which represents PCEF 122 implemented by GGSN107) and Messaging Gateway 108.

The integration with operator network 110 will be described below withreference to FIGS. 7-9. The integration with wireless communicationdevices (e.g., cellular device 100) will be described below withreference to FIGS. 10-15. Finally, the integration with operator ITsystem 150 will be described below with reference to FIGS. 16-22.

CSP—Network Integration

As shown in the embodiment of FIG. 6, the integration with operatornetwork 110 enables the ability of CSP system 530 to have real-timevisibility of usage and take real-time actions. The two networkfunctions with which CSP system 530 integrates are GGSN 107/PCEF 122 andmessaging gateway 108.

The network integration enables fast time to market without compromisingnetwork integrity or service quality. In one embodiment, the integrationis achieved through the use of standard 3GPP interfaces (Gx, Gy) andstandard Short Message Peer-to-Peer (SMPP) interface.

FIG. 7 illustrates an embodiment of the interfaces between operatornetwork 110 and PCRF/OCS 710. As described above in connection with FIG.1, PCRF/OCS 710 may reside within CSP network 170 (e.g., PCRF 173 andOCS 174), within operator network 110 (e.g., PCRF 123 and OCS 124), orboth. In the embodiment of FIG. 7, it is shown that PCRF/OCS 710 residesoutside of operator network 110 (that is, within CSP network 170).However, if PCRF/OCS 710 resides within operator network 110, CSPnetwork 170 can receive relevant information from operator network 110in real time or near real time. The CSP functions, as described beforein connection with FIGS. 5 and 6, can be embedded within PCRF/OCS 710.Thus, it is understood that the exact location of PCRF/OCS 710 is notgermane to the disclosure herein.

Referring to FIG. 7, a standard interface exists between messaginggateway 108 and PCRF/OCS 710. Message gateway 108 can be a SMS gatewayor a Short Message Service Center (SMSC). This interface to messaginggateway 108 can be a standard SMPP interface. This interface allows thesystem to deliver alerts or notifications to CDA 140 of FIG. 6 and uservia SMS.

The (Gx, Gy) interfaces are defined in accordance with the Diameterprotocol. The (Gx, Gy) interfaces are situated between GGSN 107/PCEF 122and PCRF/OCS 710. More specifically, the Gx interface is between PCEF122 and PCRF for policy, QoS control and redirection. The Gy interfaceis between PCEF 122 and OCS for real-time usage control and online datacharging.

The following describes a number of scenarios that illustrate thepossible use cases in a network system with integrated operator networkand CSP functions. Some of these use cases can be combined.

Case 1: Metering subscriber traffic with no overage allowed and noredirect to portal. In this scenario, a subscriber is assigned a monthlyquota of X MB and a threshold is set at Y %. A notification is sent tothe subscriber when the subscriber exceeds the usage threshold of Y %.No subsequent session is allowed. Quota is reset at the end of thebilling cycle.

Case 2: Metering subscriber traffic with redirect to offer portal. Inthis scenario, a subscriber is assigned a static monthly quota of X MBand a threshold is set at Y %. A notification is sent to the subscriberwhen the subscriber exceeds the usage threshold of Y %. When thesubscriber reaches 100% of the monthly quota, the subscriber session isredirected to a portal with specific offers. The subscriber selects atop-up offer and is allowed to continue passing traffic.

Case 3: Policy to throttle traffic at the end of usage quota. In onescenario, the subscriber can have unlimited usage at a lower speed witha monthly quota at a higher speed. After the monthly quota is consumed,the subscriber's data traffic is reduced (throttled) to the lower speed.In another scenario, a subscriber is assigned a static monthly quota ofX MB and a threshold is set at Y %. A notification is sent to thesubscriber when the subscriber exceeds the usage threshold of Y %. Whenthe usage reaches 90% (or any configurable percentage) of the monthlyquota, the subscriber's data traffic is reduced (throttled) to anexternally specified speed (e.g., a speed specified by the operator ofthe network). When the subscriber reaches 100% of the monthly quota, thesubscriber session is redirected to a portal with specific offers. Thesubscriber can select a top-up offer and be allowed to continue passingtraffic at the original Quality of Service (QoS). The subscriber canalso pay for a higher speed (e.g., “throttle up”) if the subscriber isaccessing a selected service (e.g., an online video) or wants morebandwidth to download a specified song or other type of file.

Case 4: Day pass. In this scenario, a subscriber is assigned a fixedduration pass. The subscriber maintains its session until expiration ofthe time quota, at which point the subscriber session gets disconnected.The subscriber is subsequently not able to reconnect until a new pass ispurchased.

Case 5: Usage control around user data volume. In this scenario, asubscriber is assigned a static monthly quota of X MB and a threshold isset at Y %. The subscriber is also restricted to use no more than Z MBof data in a 30-minute sliding window. The subscriber is redirected to aportal if data volume exceeds this restriction. Redirect in this case isone-time only. If the subscriber declines a top-up offer, then thesubscriber is reduced (throttled) to an externally specified speed(e.g., a speed specified by the operator of the network) until the30-minute sliding window is over. (Note that the QoS restrictions aresettable.)

Case 6: Usage restricted to specific Public Land Mobile Networks(PLMNs). This can be combined with other use cases. In this scenario, asubscriber is only allowed to use specific PLMNs. At some point, thesubscriber leaves the allowed networks and camps on another network. Thesubscriber attempts to setup Packet Data Protocol (PDP) context and isblocked by PCRF. Notification is sent to subscriber to offer a targetedroaming package.

Case 7: Changed QoS on Radio Access Technology (RAT) Change. This usecase assumes that the subscribers are allowed (whether as part of theplan or by explicit purchase) to have a specific QoS based on how theyare connecting to the network. In one scenario, a subscriber has no QoSrestrictions on the 3G network. At some point, the subscriber goes intoan EDGE network. Subscriber gets reduced QoS while on the EDGE network.The subscriber is provided with unrestricted speed upon returning to the3G network. This use case may be combined with other use cases.

Case 8: Subscriber has no quota limit within home network but has a 100MB quota while roaming (redirect at end of roaming quota). In thisscenario, a subscriber has no set quota while on the home network. Thesubscriber has a 100 MB quota for roaming. When the subscriber enters aroaming network, a notification update is sent to the subscriber toadvise roaming usage. At some point, the subscriber exceeds roamingusage threshold (e.g. 90% of quota). A notification update is sent tothe subscriber indicating that roaming limit has been reached. When thesubscriber reaches 100% of the roaming quota, the subscriber session isredirected to a portal for additional roaming top-up offers. This usecase can be extended to a scenario in which a local area is covered by agroup of cellular sites (cells). When a subscriber moves from one cellto another, he is not roaming (switching between networks) buttravelling (going to discrete areas in the same network). In onescenario, the subscriber has no set quota while in the home cell, buthas a set quota for travelling to other cells.

Case 9: Detect a subscriber's access to a selected (type of) website orservice. In this scenario, through the use of Deep Packet Inspection(DPI), the subscriber's access to a selected (type of) website orservice can be detected. The subscriber needs to pay for the access tothe selected (type of) website or service. This scenario is similar toanother scenario where subscribers would be redirected if they go to aweb site or location not explicitly allowed and they need to pay for theaccess.

Integration with GGSN/PCEF. FIG. 8 illustrates an example of a signalflow for a use case in which a subscriber is throttled when his quotahas been consumed. The signal flow between the GGSN/PCEF and PCRF, aswell as between GGSN/PCEF and OCS (or its equivalent), are in accordancewith the Diameter protocol. The Diameter protocol is an authentication,authorization and account protocol. The Diameter protocol defines anumber of commands, such as capability exchange request (CER),capability exchange answer (CEA), device watchdog request (DWR), devicewatchdog answer (DWA), credit control request (CCR), credit controlanswer (CCA), etc. These commands are exchanged between the GGSN/PCEFand PCRF, as well as between GGSN/PCEF and OCS, to communicate policydecision, consumed quota, threshold limit reached, change of policydecision and change of QoS. FIG. 8 shows that when a threshold quota isreached, the OCS issues a notification (810), and when the quota isconsumed, the PCRF makes the policy decision to lower the QoS (820). TheGGSN/PCEF applies the policy decision (830), which lowers the QoS of theuser data traffic (840). The signal flow of FIG. 8 does not show all ofthe Diameter parameter details for simplicity of illustration.

FIG. 9 illustrates an example of a signal flow for a use case in which asubscriber is redirected to a top-up page when his quota has beenconsumed. FIG. 9 shows that when a threshold quota is reached, the OCSissues a notification (910). When the quota is consumed, the PCRF makesthe policy decision to redirect the subscriber to a top-up page (920),and the GGSN/PCEF redirects the subscriber to the top-up page (930), andthe user data traffic continues to flow (940). The signal flow of FIG. 9does not show all of the Diameter parameter details for simplicity ofillustration.

Because the various Diameter interfaces above have many options, theintegration with one GGSN vendor may not be the same as the integrationwith another. For each make and model of GGSN and Packet Data NetworkGateway (PGW), specific GGSN templates can be used. These specifictemplates include only the parameters and settings that have been provenagainst the corresponding make and model of GGSN. In terms of Diameterinterfaces, only the Access Point Names (APNs) (i.e., the networkaddresses used to identify one or more GGSNs) that have been proven forthe PCRF/OCS and the particular GGSN are used.

The CSP-integrated PCRF and OCS include an upwards-facing API (alsoreferred to as northbound-facing) and Java Message Service (JMS) queue.These are used for passing usage information and event information tothe higher layers of CSP system 530 (FIG. 6) and for issuinginstructions from higher layers towards the PCRF and OCS. For example, aPCRF or equivalent instructs the GGSN/PCEF as to the QoS to be appliedfor a subscriber and the usage to be allowed. When the user has consumeda specific threshold, OCS or equivalent notifies the PCRF or equivalent,which in turn queries the recommendation engine to determine arecommendation to present in a notification and offer to the subscriber.If the user reaches 100% of his allocated quota, then OCS informs thepolicy and rating engine, which instructs the GGSN/PCEF to change theQoS to throttle the user.

The use of CSP-integrated PCRF and OCS allows for fast time to marketand retains the full value proposition of the CSP solution. However, thehigher-layer functions of CSP can integrate with any PCRF and OCS (e.g.,an operator's own PCRF and OCS) that can provide the required interfacesfor notification and control of the PCRF and OCS functions themselves.

As the PCRF and OCS may be tightly integrated with CSP system 530, whena user selects a new plan, that plan can be provisioned through the PCRFand OCS in real time. Thus, the subscriber can be served immediately. Itis necessary that the other systems, such as customer care, within theIT infrastructure are aware of the new plan being provisioned. For thatreason, as explained later, CSP system 530 interfaces to the operator'sprovisioning/order entry system. In one embodiment, CSP system 530 maymanage the provisioning/order entry of data service upgrades with theCSP-integrated PCRF and OCS.

Integration with Messaging Gateway.

CSP system 530 (FIG. 6) can communicate with CDA 140, as well as otherdevices if the operator so wishes, via a proprietary or non-proprietaryIP-based communication protocol, such as SMS, Unstructured SupplementaryServices Data (USSD), Apple® Push Notification Service (APNS) for iOSdevices, Android® Cloud Device Messaging (ACDM) for Android® devices,and the like. SMS can be used to wake up CDA 140 when needed. Forexample, SMS can be sent to a consumer as an alert or notification whendata usage limit is reached, payment is overdue, or a promotion relevantto the consumer is available. In one embodiment, the alert andnotification can be generated by network elements (such as PCRF/OCSwithin either operator network 110 or CSP network 170), and delivered tothe consumer's CDA 140 by CSP system 530. In a scenario where theoperator wishes to recruit existing subscribers to the use of CDA 140,CSP system 530 can use SMS to signal these subscribers' devices with alink to download CDA 140.

In some embodiments, operators have SMSCs to forward text messagesto/from external systems. These SMSCs support protocols such as SMPP orUCP. Some operators also use messaging gateways as an interface to theexternal systems, thereby minimizing direct connections from externalsystems to the SMSCs. These gateways also support SMPP or UCP, and mostalso have other APIs that can be made available. In alternativeembodiments, the SMSCs may be part of CSP system 530.

In some embodiments, CSP system 530 has built-in SMPP clientfunctionality. CSP system 530 can integrate with the operator'smessaging gateway 108 using SMPP. In one embodiment, a specific shortcode can be assigned to CSP system 530 and that short code iszero-rated. Thus, messages between CSP system 530 and the user devicewill not be charged to the user's account.

CSP—Application Integration on a Wireless Communication Device

FIG. 10 illustrates an example of CSP device application (CDA) 140 whenused on a smartphone device. Although a smartphone is shown, it isunderstood that CDA 140 can be run on cellular device 100 (FIG. 1) suchas a cellular telephone, a tablet computer, a personal digital assistant(PDA), a video-camera, a gaming device, a global positioning system(GPS), an e-Reader, a Machine-to-Machine (M2M) device (i.e., anapplication-specific telemetry device that collects data using sensorsand transmits the data to a destination such as a server over anetwork), a hybrid device with a combination of any of the abovefunctionalities, or any other wireless mobile devices capable of sendingand receiving voice, data and text messages. CDA 140 serves as aninterface between the operator and the customer. CDA 140 receivesinformation from CSP system 530. CSP system 530, in turn, receives theinformation from operator network 110, operator IT system 150, and CSPnetwork 170 (FIG. 1). CDA 140 can be operator branded and can be builtusing a combination of multiple programming languages for Web and Mobiletechnologies, e.g. C++, HTML5, Java, OS-specific native applicationcode, etc., and other mobile Web technologies. CDA 140 is an application(or construct) that is resident and accessed from the device. Customerscan be given access to the application in several ways; e.g., bypre-loading on new customer devices at the device OEM, by downloading toexisting devices using a link to the appropriate application store,and/or accessed via a mobile Web page sent to the customer.

While CDA 140 is a device-based application, a majority of its data andexperience (e.g., displayed layout and content) are generated and servedfrom CSP system 530. This provides the ability to dynamically displayand change elements of the experience without pushing applicationupdates to the user device. In one embodiment, CDA 140 communicates withCSP system 530 over Hyper-Text Transfer Protocol Secure (HTTPS), whichuses multi-layer authentication architecture to validate CDA 140,handset and user, before allowing access to data and functions such aspurchasing upgrades. Alerts and notifications may be delivered to theuser device via SMS through the CSP-Messaging integration describedabove, as well as through Mobile OS-specific notification methods; e.g.,APNS for iOS devices and ACDM for Android® devices.

In one embodiment, the recommendation engine (which is one of CSPengines 122 in CSP system 530 shown in FIG. 6) is the CSP's mechanismfor creating real-time contextual offers. In the embodiment shown, therecommendation engine analyzes the information collected from CRM, CDRs,campaigns, and the like by data mining and micro-segmentation. Thecustomer micro-segmentation allows an operator to target a certainsegment of the subscribers to make offers that are most relevant tothose subscribers. The recommendation can be made with respect to anumber of factors of contextual assessment, such as time in contract,loyalty status, purchase history, value of customer, and data and timeusage. The recommendation engine creates or recommends real-time offersbased on results of customer profiling, as well as factors of thecontextual assessment and information received from PCRF, OCS and CDRs.Thus, when a consumer's real-time usage reaches a limit and receives areal-time alert, the offers that are created by the recommendationengine and approved by the operator can be delivered to the user deviceinstantly. CDA 140 directly interacts with CSP system 530. Via CDA 140,a consumer can choose one of the offered options that are displayed onhis device in a user-friendly format. The chosen option can beprovisioned to the user in real time and feedback can be sent back tohosted service platform 120 in real time.

FIGS. 11-15 illustrate examples of the functions provided by CDA 140according to embodiments of the invention. Referring to FIG. 11, aseries of screen displays of CDA 140 is shown in connection with atop-up offer for data usage. Initially, a home page (1100) provides anumber of options, one of which is “My Account.” By selecting the usagetab in the My Account page, the user's usage for voice, text message anddata is displayed on the user device (1101). The display shows theuser's data usage is at 92% of the quota limit. Automatically or byuser's selection, a top-up offer page (1102) including multiple optionsis shown to the user. Each option is an offer created by therecommendation engine based on the contextual assessment described inconnection with FIG. 6, and approved by the operator. If the userselects one of the options (1103), a purchase confirmation page (1104)will be shown on the display. At that point, the usage page (1105) showsthat the user's quota has been increased and the data usage is now at81% of the quota limit.

The “My Account” feature allows a user to check his current usageinformation whenever he wants to. If the user does not take theinitiative to check his current usage and limits, he can be notified byalerts of situations that can lower his QoS or disable his networkconnections. Alerts will be described with reference to FIGS. 15A and15B.

In one embodiment, the “My Account” feature also allows a user tomonitor the billing; e.g., the amount of money he spent on networkservices before receiving a billing statement. For example, if the useris roaming and incurring roaming charges, he can monitor the amount ofroaming charges in his account by clicking on the “billing” tab on thetop right corner.

Referring to FIG. 12, a series of screen displays of CDA 140 is shown inconnection with a “Tell-a-Friend” feature. Initially, a home page (1200)provides a number of options, one of which is “Deals.” The Deals page(1201) shows all of the currently available deals relating to wirelesscommunication services and devices. A user can select a tab to filterthe displayed result; for example, deals offered by a particularprovider, vendor or operator (1202). A user can select a “Friends” tab(1203) to show the deals recommended by his friends. By clicking into aparticular offer (1204), the user can make a purchase in real time orsave the offer for later consideration. A purchase confirmation page(1205) is displayed when the user makes a purchase. The user can sharethe information about this offer with his friend by clicking a softbutton “Send Message” to send a generic or personalized message (1206).

Referring to FIG. 13, a series of screen displays of CDA 140 is shown inconnection with a “Help” feature, which performs diagnosis and provideshelp. In one embodiment, the diagnosis is performed by the user'sdevice, taking into account the information collected by CSP system 530from many data sources (e.g., PCRF, OCS, CDRs, CRM, etc.). The diagnosiscan be performed in the following areas: the user's coverage,subscription, usage, payment, roaming status, and the like. Initially, ahome page (1300) shows that all services are currently available. A usercan select a number of options, one of which is “Help,” to explore moreinformation. Clicking into the help page (1301) automatically activatesa diagnostic function. In this example, the diagnostic function findsthat the user's payment is overdue. By clicking on the diagnosed problem(payment), the user can go to a page displaying payment options (1302).The user can make payment by credit and debit cards (1303 and 1304). Apurchase confirmation is shown after the payment is accepted (1305).

As shown in the example above, the “Help” feature not only discovers aproblem, but also provides a resolution to the problem in auser-friendly way. In another scenario, a user may find out from thediagnosis that he does not have coverage. This diagnosed problem(coverage) can re-direct him to one or more proposed solutions, such asmoving down the road 10 miles or purchasing an upgrade to the networkcoverage.

FIG. 14 illustrates an example in which a connection problem isautomatically detected without the user proactively running thediagnostic function. In this example, the top panel of the display showsthat a connection problem has been detected (1400). The user can click a“Fix Now” soft button and see a list of questions that are relevant tothe detected problem (1401). The user can select one of the questions tofind more information; e.g., the user's current status that is relevantto the cause of the detected problem (1402). In this scenario, a voicetest is recommended. The user can run the voice test to test his/hervoice connection (1403 and 1404). For example, the user device can senda message to request a voice network component in the operator networkto call the user device. If a problem is found, the user can choosewhether to report the problem to the operator (1405). If the userchooses to report the problem, a report confirmation page (1406) isdisplayed. In other scenarios, the user can run a data connection testor a messaging test to request a data server or a messaging server inthe operator network to call the user device. This “Help” feature isanother example of a contextual action that provides a clear pathtowards resolution of an issue that a user current has.

FIG. 15A illustrates an example of a “User Alert” feature. In thisexample, when a user reaches his quota limit, the top panel of thedisplay shows an alert and a top-up offer (1500). The alert may showthat the user has exceeded his usage threshold but is still within thequota limit, or that the user has reached the quota limit. The user canselect a top-up offer from the top panel without clicking into deeperlevels of the menu (1501), or review more plan upgrade options. Afterthe user selects the top-up offer and makes the purchase, a purchaseconfirmation page is displayed (1502). As described in connection withFIG. 6, the top-up offer and upgrade options can be created by therecommendation engine based on contextual assessment of the user'sunique situation, and approved by the operator.

FIG. 15B illustrates an example of a “Roaming Alert” feature. In thisexample, a user roams into another network (or another area) but hisplan does not support such roaming. The display shows an alert and anumber of options (1530). The user can select any of the options toenable the roaming (1531). Each option is an offer created by therecommendation engine based on the contextual assessment described inconnection with FIG. 6, and approved by the operator. After the userselects one of the options and makes the purchase, a purchaseconfirmation page is displayed (1532).

CSP—IT Integration

Referring again to FIG. 6, in one embodiment, CSP system 530 integrateswith four functions of operator IT system 150 in the areas of CRM/care610, provisioning/order entry 620, billing/payments 630 andreporting/DWH 640. CSP system 530 integrates with each of the four areasthrough a corresponding interface. The CRM interface supports rating,policy and offer management, campaign management and customer managementand care. The provisioning/order entry interface enables the activationof selected services within the operator systems. The billing interfaceallows usage information to be shared with CSP system 530. Thus, a usercan see his up-to-the-minute usage via CDA 140 without having to contactcustomer care. The reporting interface makes available the CSP-generatedreports to all necessary functions within the operator.

The CSP experience provides both the consumer and the operator a numberof self-service tools that can be used anytime and anywhere to managetheir services. For the consumer, CSP system 530 offers the ability tosee, select and purchase new services, as well as perform accountmanagement and self-support activities, such as account balanceinquires, payment method changes; all from their smartphones (or anotherwireless communication device) and all in real time.

For the operator, CSP system 530 provides a suite of tools that enablesthe creation and management of all of the services and experiencesreceived by the customer. For example, the operator's CRM system 610 canintegrate with CSP system 530 to provide details on offers and servicesthat CSP system 530 can recommend to the customer as upsells or standardsales offers, to view current account balances and usage, managepayments and to provide diagnostics to assist the user with self-serviceresolution of common support issues. CSP system 530 can also integratewith the operator's reporting and data warehouse systems 640 to providefinancial, marketing and management reporting.

In one embodiment, integration between CSP system 530 and operator ITsystem 150 is based upon the availability of interfaces to selectedsystems and/or groups of systems. As CSP system 530 uses a model thatabstracts its interfaces to the operator platform using an adaptationlayer, these interfaces can vary from standards-based Web services APIsto secure file transfers.

In one embodiment, the interfaces enable not only the integration of CSPsystem 530 with operator IT system 150, but also the ability for anoperator to manage its marketing campaign, offers, pricing, billing andcustomer care in an integrated environment. In one embodiment, thisintegrated environment is presented to the operator via CSP operator Webapplications 154. CSP operator Web applications 154 may be run on acomputer in the control center of operator IT system 150.

FIG. 16 illustrates an embodiment of a screen display of CSP operatorWeb applications (e.g., CSP operator Web applications 154 of FIG. 6). Inthis embodiment, the screen display includes a top panel that showsalerts and status 1601 and campaign results 1605. Alerts and status 1601allows an operator (or more specifically, the administrators at theoperator side) to communicate with each other with respect to the latestupdates and status of operator network 110 and operator IT system 150(FIG. 6). In one embodiment, the main panel of the display is dividedinto three regions: Create Offers and Policy 1602, View CustomerActivity 1603 and Manage Communications 1604. Each of the three regionsincludes a number of task modules 1610-1618 that allow theadministrators to perform specific tasks. The backend of task modules1610-1618 is CSP system 530, or more specifically, CSP engines 122 (FIG.6). When an operator clicks on any of task modules 1610-1618, theoperator can be provided with templates and data that are generated byone or more CSP engines 122. CSP engines 122 generate the templates anddata based on the information obtained from operator network 110 andoperator IT system 150 (FIG. 6). In one embodiment, access to these taskmodules 1610 can be role-based; that is, an administrator with amarketing role may be able to access only a subset of task modules1610-1618 while an administrator with a manager role may be able toaccess all of task modules 1610-1618.

In one embodiment, some of the task modules, such as pricing workstation1610 and offers workstation 1611, allow the administrators to createoffers and set pricing. In one embodiment, CSP system 530 can provideoffers and pricing templates for the operator to fill in the details.Through subscriber portal 1612, an operator can design subscriber'son-device experience, also using the templates provided by CSP system530. These templates allow the operator to set a pricing plan andpackage the pricing plan into an offer associated with a policy. Thepricing, offer and policy are sent to CSP system 530 to allow CSP system530 to deliver the right offers with the right pricing to the rightsubscribers at the right time. CSP system 530 can also provide othertemplates that can be used by the operator with a click on any of taskmodules 1610-1618.

In one embodiment, an operator can view the details (e.g., activitiesand history) about subscribers through the task module of subscriberdetails 1613, and perform operations on their accounts; e.g., activateor deactivate the accounts, change offers, apply promotions and otheraccount administrative tasks. Custom alerts 1614 allow administrators ofthe operator to configure rules for alert-triggering events. Thesealerts may be accompanied by automated response to specific events forresolving the condition causing the alerts. The task module of reports1615 allows the operator to review and analyze subscriber and financialdata. For example, the operator can run a report to find out when aparticular offer or a particular group of offers have reached a setmarket share or set usage.

In one embodiment, an operator can design campaigns to send offers andincentives to specific subscribers using campaign center 1616. In oneembodiment, the offers and incentives can be delivered to CDA 140 on theuser device via CSP system 530 (FIG. 6). In one embodiment, CSP system530 can provide campaign templates for the operator to determine thespecific details of campaigns. For example, the operator can decide on aplan and the recommendation engine of CSP system 530 can recommend asegment of subscribers to whom this plan should be offered.Alternatively, the operator can decide on a segment of subscribers andthe recommendation engine can recommend a plan to offer to thesesubscribers.

In one embodiment, an operator can use customer alerts 1617 to set up analert for specific subscribers and the rules associated with the alert.The alert can be displayed on the user device to allow a subscriber totake remedial action; e.g., to accept a top-up offer that is deliveredwith the alert to the subscriber. In one embodiment, the task module ofanalytics 1618 is backed by the recommendation engine of CSP system 530.Analytics 1618 allows the operator to identify trends and opportunitiesbased on the subscribers' behavior and campaign results. For example, ifthe subscriber reaches his usage limit for the first time, analytics1618 can recommend a top-up offer (which is valid only for this currentbilling cycle). If this is the fifth time within a five-month periodthat the subscriber has reached the threshold, analytics 1618 canrecommend an upgrade offer such that the subscriber can switch to anupgraded plan and receive a higher quota limit every billing cycle.

As mentioned before, the integration of CSP system 530 and operator ITsystem 150 (FIG. 6) enables the functionality of CSP operator Webapplications 154 described above. The following describes thisintegration with respect to CRM/care 610, provisioning/order entry 620,billing/payments 630 and reporting/DWH 640 (FIG. 6).

CRM Integration.

FIG. 17 is an overview of CRM integration according to one embodiment ofthe invention. Referring also to FIG. 6, CSP system 530 includes a CSPCRM API 1701, which interacts with operator IT system 150 to manage orrecommend strategies for CRM and care. Through CSP CRM API 1701, theoperator's CRM system 610 is fed with usage and diagnostic data from CSPsystem 530, and CSP system 530 pulls customers profile information andupdates from the CRM system 610. In one embodiment, CSP system 530integrates with the operator's CRM system 610 in the following areas:Rating, Policy and Offer Management; Campaign Management; and CustomerManagement and Care.

CRM Integration Area (I): Rating, Policy and Offer Management (ProductCatalog).

Through the integrated rating, policy and offer management functions,CSP system 530 provides the operator a powerful set of tools to create,edit, approve and manage rate plans and policy actions for consumers. Asthe front-end interface to an integrated OCS and PCRF facility, CSP'sPricing and Offers engines (e.g., CSP engine 122 of FIG. 6) integratewith the operator's Product and Policy Catalog to pull current offersand create new offers and policy rules.

Depending on the nature of the product deployment, CSP system 530 canreplicate offers currently in the operator's product catalog, create andpush offers to the operator, or act as the master product catalog forrating. In all of these three cases, CSP CRM API 1701 provides propersynchronization between CSP system 530 and operator IT system 150, aswell as ensuring availability of offers and policies. CSP CRM API 1701allows CSP system 530 to access and pull offers. CSP CRM API 1701 alsofacilitates a submit/approve/publish method to push offers to theoperator.

Through CSP CRM API 1701, CSP system 530 pulls all applicable offers,catalog rules, offer parameters and policy descriptions into aneasy-to-use, self-service user interface that the operator's marketingpersonnel can use to quickly create new offers and promotions. Inpractice, the process to create and approve an offer touches manyinternal operator departments and may need some level of internalcoordination and process to accomplish. To properly engage with andmanage this need, CSP system 530 has an integrated approval workflow toprevent the use of these offers and policies until they are reviewed andapproved by the appropriate operator-designated personnel. Onceapproved, the offers and policies can be pushed to the operator usingCSP CRM API 1701 or a similar API.

A sample product catalog/rating/policy template is shown below.

TABLE 1 Sample (Basic Offer) Product Catalog Template Catalog Area FieldName Description Identification Offer Code Operator's offer code used toidentify the offer to CRM and other systems Offer Friendly Name Name ofthe offer that will be presented in the CDA Applicable Service Type(s)Service Type that this offer is applicable to (voice, data, etc.)Effective/Expiration When offer can be used/stops being offered Date(s)Compatible Offer Code(s) Codes of offers that are compatible (allowed tobe purchased) with this offer Allowed payment types Payment types(debit, credit card, prepaid) allowed for plan purchase Rates PrimaryRating Type First rating scheme as applicable to service type (by unitsof usage, time, destination, etc.) Rating Amount Amount charged forrated usage Secondary Rating Type Additional rating scheme as applicableto service type (by units of usage, time, destination, etc.) RatingAmount Amount charged for rated usage Policy Policy Conditions Selectedpolicy conditions, e.g. throttle, redirect, notify Policy ActionsParameter and action when policy condition is met Type of Offer Standardoffer, upsell or both.

In case an API is not or cannot be made available, a manualsynchronization process can be used to perform the actions that would betaken by the API. In this manual approach, the operator uses the CSPPricing and Offer engines to create and publish the appropriate offersand policies. A key to success in this approach will be the creation ofbusiness processes that govern the speed and frequency of updates.

FIG. 18 illustrates an example of an operation sequence that allowsoffers created by CSP system 530 to be modeled and managed in theoperator's product catalog. In one embodiment, CSP system 530 creates anoffer/policy template (or zero-rated offer) (1801). CSP system 530 thensubmits that offer/policy to the operator for approval (1802). CSP CRMAPI 1701 publishes the offer/policy to the operator (1803). Upon receiptof the offer/policy, operator IT system 150 creates shell offer code anddescription (e.g., by associating the parameters of that offer (OfferCode, etc.) to the CSP-created offer) (1804). Operator IT system 150then propagates the offer/policy to downstream systems (1805). Thus, alldownstream systems that are fed from the product catalog (Care, Finance,Reporting, etc.) receive information and updates during the normalcourse of business. Through CSP CRM API 1701, operator IT system 150also publishes the approval to CSP system 530 (1806). Upon receipt ofthe operator's approval (1807), CSP system 530 makes the offer/policyavailable for use by the customers (1808).

CRM Integration Area (II): Campaign Management.

In one embodiment, CSP system 530 includes Customer Alerts and Campaignengines (e.g., one or more of CSP engines 122 of FIG. 6), which useoffers generated by the Pricing and Offer engines (e.g., one or more ofCSP engines 122 of FIG. 6) to provide customers with automated andoperator-generated upsell offers. The Customer Alerts engine allows theoperator personnel to create and set automated alerts that providecustomers notification of key lifecycle events, e.g. reaching a usagethreshold, approaching a bill cycle date, accessing a non-includedservice such as roaming. Included in these alerts can be contextuallyrelevant upsell offers that allow the customer to continue usingservices. The Campaign engine allows the operator's marketing personnelto either use CSP's integrated recommendations engine (one of CSPengines 122 shown in FIG. 6) to identify targeted lists of customers forreceiving promotions, or to upload a pre-segmented list.

TABLE 2 Integrations Supporting Campaign Management Required FunctionDescription Addressed in Integration Area Usage data Provides campaignanalytics and Network recommendation Notifications Sends SMS messages tocustomers that have received a campaign Service offers and Offers thathave been approved for use Rating and Policy (Product upsells ascampaigns and upsells Catalog) Opt-In Customer's preference to receivealerts, Customer Profile notifications and campaigns from the OperatorPersonalization Information to create a more personal campaign as wellas validate that the campaign is sent to the right consumer Report andSource In the case that the Operator uses their Data Warehouse Data ownpre-segmented list of target customers.

CRM Integration Area (III): Customer Management—Customer Profile.

CSP system 530 is designed to address the sensitivity of the operator'scustomer data and the number of regulatory and legal issues. Integrationbetween CSP system 530 and the operator's CRM customer profile is neededto enable several functions: authentication of CDA 140, personalizationof offers and alerts, and knowledge of customer offers forrecommendations and account management. In all cases, CSP system 530looks to the operator's CRM system 610 as the master record for allcustomer data.

To protect end-customer data, all of the end-customer data is storedwithin the CSP customer database and managed in a manner that enables itto be secure and auditable at all times. Any changes made to thecustomer data are tracked using an audit trail that can be madeavailable for reports, audits, etc. In addition, the CSP data centerscan be deployed in specific geographical locations to accommodate datasecurity, privacy and location requirements.

The integration that is required to store and update this data insideCSP system 530 can be accomplished using an API (e.g., CSP CRM API 1701of FIG. 17) that enables data to be pulled from the operator's CRMsystem 610 using a commonly used and relatively unchanged key. In oneembodiment, the key can be the International Mobile Subscriber Identity(IMSI) followed by the Mobile Station International Subscriber DirectoryNumber (MSISDN). Depending on the nature of the product deployment,customers may be allowed to update their data through the CDA 140, e.g.change billing methods, addresses, etc. In this case, the same approachis recommended to update customer data inside the operator's systems.

Since the customer profile data feeds CSP's customer database andcontains all of the customer's current plan information, the CRMintegration also enables changes made outside of CSP system 530 to bereflected in the CDA 140 and CSP system 530. Thus, any changes to ratingor policy parameters can be properly synchronized between CSP system 530and the operator. To that end, changes made within the operator'scustomer care and/or retail ordering systems are pushed (recommended) orpulled periodically from the operator's CRM system 610 to CSP system530. The CRM integration allows CSP system 530 to be constantlyup-to-date with the operator's systems. In one embodiment, the API(e.g., CSP CRM API 1701 of FIG. 17) allows customer data to be rapidlyaccessed and updated. This is necessary because customer profile data isused in the display of account management functions, as well as a keyinput into the CSP recommendations engine.

In one embodiment, CSP system 530 uses the following information in thecustomer profile for CRM integration:

TABLE 3 Customer Profile Fields and CSP Functions that Use These FieldsField Name Description Authentication Recommendation AccountMgt IMSICustomer's IMSI x MSISDN Customer's phone x number Customer NameCustomer's billing x x name Billing Account the Operator's x x Numberbilling account for customer Contract Date Original contract x x(tenure) date or tenure of customer Current Plan Type Prepaid or x xpostpaid Current Voice Plan Current plan x x Current Data Plan x xCurrent Messaging x x Plan Current “other” Plan Current non- x x mobileor other service plan Bill Cycle Date Postpaid bill cycle x x date orprepaid expiration date Previous Voice Plan Most recent x x PreviousData Plan changed plan x x Previous Messaging x x Plan Previous “other”x x Plan IMEI/Device Type Device type x x identifier or IMEI - thelatter is preferred Opt-In Status Customer's x election to receivenotifications Campaign Opt-In Customer's x Status election to receivecampaigns and promotions Current campaign Campaign x customer iscurrently attached to (if any)

CRM Integration Area (VI): Customer Management—Customer Care.

CSP system 530 has a number of customer management capabilities that canbe useful to the operator's customer care and customer management teams.

In one embodiment, CSP system 530 does not directly push data into theoperator's CRM system 610. Rather, it assumes that integrations arealready in place within the operator's infrastructure to passinformation, for example, from the product catalog,provisioning/ordering and similar systems to the CRM system 610. If adirect push integration to the CRM system is necessary, CSP system 530can provide information via an API to the CRM system 610 on a per-eventor time-basis.

In one embodiment, CSP system 530 can, via an API, allow the operator'sCRM system 610 to provide diagnostic, current offer and current usagedata. Since CSP system 530 is both the rating and policy managementengine, a customer current usage and policy status, e.g. throttled ornot throttled can be made available to the CRM system 610. One keycomponent of the CSP system 530 is the ability to push advanced serviceand network-level diagnostics to the handset and provide the user timelyand actionable feedback to solve issues.

While one of the key attributes of the CSP system 530 and CDA is theability to allow a customer to perform a majority of account managementand self-support issues, it may be unavoidable that sometimes thecustomer will call customer care. When the customer does call customercare, the customer care agent (or a technical support representative)can, via the API, pull diagnostic information into their normal systemsand provide assistance to the customer. In the case where the CRM systemcannot integrate to an external data source, CSP system 530 can be setupto launch-in-context (LIC) along with the customer care representative'sexisting tools.

Provisioning/Order Entry Integration.

Prior to the description of provisioning/order entry integration, it isuseful to differentiate between order management and provisioning/orderentry functions. Order management functions aggregate customerselections for offers, payment methods and any other updates and passthat information to a provisioning/order entry system that allows accessto those ordered services on the network.

Since CSP system 530 may be the master rating and policy engine, it canenable access to the selected services and then integrate with the ordermanagement system to feed data to downstream systems, e.g. care,reporting and CRM. This integration assumes the existence of interfacesbetween the order management and related downstream systems (e.g., CRMand reporting) to manage activities such as customer activation, servicechanges, device changes and updating financial and marketing reports.

FIG. 19 is an overview of provisioning/order entry integration accordingto one embodiment of the invention. Referring also to FIG. 6, CSP system530 includes a CSP provisioning/order entry API 1901, which interactswith operator IT system 150 to manage service provisioning/order entry.In one embodiment, CSP provisioning/order entry API 1901 defines serviceoffer codes (SOCs) for offers that are applicable to one or morecustomers. When the customer selects an offer, CSP system 530 provisionsthe selected service against the SOC code. The selected offer is thenpropagated to other systems (e.g., CRM and billing). Through CSPprovisioning/order entry API 1901, CSP system 530 can be notified ofchanges to customer profile, and CSP-created offers can be pushed to theproduct catalog.

In one embodiment, CSP system 530 is provided with the appropriateidentifiers for all available provisioned services. These codes (andassociated parameters) are known as service offer codes (SOC) and can beused by CSP system 530 to inform the provisioning/order entry system toallow a customer access to their selected offers. For data services, CSPsystem 530 can provision service access on its integrated PCRF basedupon the customer's selections, and submit, via CSP provisioning/orderentry API 1901, the appropriate SOC, any relevant parameters and acustomer identifier (IMSI or MSISDN) directly to the provisioning/orderentry system for fulfillment. In parallel, CSP system 530 can send thesame information via a Web services interface to the operator's ordermanagement system for further processing and population of downstreamsystems. In an alternative embodiment, the operator can choose toprovision its PCRF with the same information as CSP system 530.

FIG. 20 illustrates an example of an operation sequence that provisionsthe offers selected by customers. In one embodiment, CSP system 530validates offer rules and restriction (2001), and signals CDA 140 todisplay offers (2002). When the customer selects an offer (2003), CDA140 captures the offer and order information (2004). In response, CSPsystem 530 enables access to selected services (2005). At this point,CSP system 530 generates and sends the order to operator IT system 150via an API (e.g., CSP provisioning/order entry API 1901) (2006), and inparallel, signals CDA 140 to display service confirmation (2010). Whenoperator IT system 150 receives the order from CSP system 530 (2007), itupdates CRM and customer profile (2008) as well as downstream systems(2009). After CDA 140 displays service confirmation (2010), the customercan start using the selected services (2011). CDA 140 can furtherdisplay updated details in My Account (e.g., the My Account featureshown in FIG. 11).

CSP system 530 also offers the ability to offer and provision othermobile (voice, messaging) and non-mobile services (DSL, insurance) thatare not rated by CSP system 530. In this case, CSP system 530 can, usingthe same mechanisms noted above, provide the provisioning/order entryand ordering systems the appropriate SOC (or equivalent) code, allowingthe appropriate network elements (e.g., HLRs) and IT platforms (CRM) tobe updated. To that end, all of the products and services offered by theoperator need to be provided to CSP system 530, placed in the productcatalog and synchronized.

As previously noted, CSP system 530 receives information about acustomer's current services and selections from the customer profiledatabase. If a change is made to the customer's plans or services viathe Care or Retail system, these changes and their associatedprovisioning/order entry changes are sent to CSP system 530.

Billing Integration.

In one embodiment, CSP system 530 integrates with the operator's billingsystem in the following areas: Rating of Data Usage, Self-ServiceAccount Management and Risk Management and Payment.

FIG. 21 is an overview of billing integration according to oneembodiment of the invention. Referring also to FIG. 6, CSP system 530 ofFIG. 6 includes a CSP billing API 2101, which interacts with operator ITsystem 150 to manage billing and payments. In one embodiment, throughCSP billing API 2101, CSP system 530 pushes rated data CDRs tobilling/mediation system, and billing/mediation system pushes ratedvoice and SMS to CSP system 530. CSP system 530 is integrated forcredit/debit processing. CSP system 530 can push payment details tooperator's billing/mediation system. The operator's billing system doestax, invoice and collection.

Billing Integration Area (I): Rating of Data Usage.

In one embodiment, a CSP-integrated OCS can be used to rate data usagefor customers that are managed by CSP system 530. The rates and policiesused by the OCS can be stored and managed by CSP system 530.

In one embodiment, CSP system 530 can rate usage and calculate chargeson a per session basis. Depending on the nature of the productdeployment, CSP system 530 can either store, aggregate and format usageinto an invoice-ready format, or send rated, per-session usage to theoperator's CRM or other system. If the former, CSP system 530 canprovide the invoice-ready data feeds to a mutually agreed sFTP site forthe operator to pick up and include into its billing process a setnumber of days prior to the close of the billing cycle.

In the latter option, CSP system 530 can post, on a per-session basis,aggregated usage including the customer identifier (IMSI or MSISDN),plan code and total usage. In one embodiment, this integration will bemanaged through the use of an API (e.g., CSP billing API 2101) that candirectly feed the operator billing system. A known analogue to this typeof integration is one where a third party provides a “bill on behalf of”service to an operator. In this case, CSP system 530 will be chargingdata usage on behalf of the operator and providing that rated usage foruse by downstream financial systems (e.g., taxation) as well as CRM andreporting systems. If an API cannot be made available, these data can beposted to a sFTP site.

Billing Integration Area (II): Self Service Account Management.

A key feature of the CDA 140 is the ability for the customer to view, inreal time, current service usage. In an embodiment where CSP system 530is rating data and the operator is rating voice and SMS, it is necessaryto integrate with the operator's usage management systems to get ratedand/or aggregated usage for those services. Depending on the operatorsystem that sources this data, a push API or sFTP file transfer can beused to get these data. A key factor in determining how to perform thisintegration is how fast the usage information can be made available viathe interface. If there is a delay greater than a pre-defined timeperiod (e.g., 15 minutes between usage completion and CDR delivery), asecondary method may be used to enable the “real-time” nature of the CDA140 account management function. In this case, the customer profileintegration may be a candidate to pull current, aggregated usage.

Billing Integration Area (III): Risk Management and Payment.

Depending on the nature of the product deployment, CSP system 530 canalso integrate with the operator's risk management and payment systems.The integration with these services is highly dependent on the serviceused and where it sits within the operator infrastructure. The idealintegration with CSP system 530 is to use an existing interface, e.g.the customer profile to determine the risk score for a customer and usethat along with the catalog rules sourced from the product catalogintegration to determine payment risk.

In addition, CSP system 530 can, as part of the order management andprovisioning/order entry transaction, send a payment type and paymentdetails. This is necessary if the operator wants to enable prepaid orcredit card payments for services purchased via CDA 140. In this case,the integration is also highly dependent on the target system and itslocation within the operator infrastructure. Typically, CSP system 530can interface with but does not actually store or process any payments.

Data Warehouse/Business Intelligence Integration.

FIG. 22 is an overview of data warehouse integration according to oneembodiment of the invention. Referring also to FIG. 6, CSP system 530 ofFIG. 6 includes a CSP reporting API 2201, which interacts with operatorIT system 150 to manage data warehouse. In one embodiment, through CSPreporting API 2201, CSP system 530 can push reports to operator ITsystem 150 using a sFTP interface or a similar interface. The sFTPinterface can be over the Internet. In some embodiments, a VirtualPrivate Network (VPN) can be used for additional security.

In some embodiments, CSP system 530 provides over twenty reports for useby an operator, such as daily subscriber report, usage detail reports,reports on charges of all kinds, and the like. Reports can be generateddaily and/or monthly, and delivered to the operator.

Thus, a method, system and apparatus for a Core Service Platform (CSP)has been described. It is to be understood that the techniques shown inthe figures can be implemented using code and data stored and executedon one or more electronic devices (e.g., an end station, a networkelement, etc.). Such electronic devices store and communicate(internally and/or with other electronic devices over a network) codeand data using non-transitory machine-readable or computer-readablemedia, such as non-transitory machine-readable or computer-readablestorage media (e.g., magnetic disks; optical disks; random accessmemory; read only memory; flash memory devices; and phase-changememory). In addition, such electronic devices typically include a set ofone or more processors coupled to one or more other components, such asone or more storage devices, user input/output devices (e.g., akeyboard, a touch screen, and/or a display), and network connections.The coupling of the set of processors and other components is typicallythrough one or more busses and bridges (also termed as bus controllers).The storage devices represent one or more non-transitorymachine-readable or computer-readable storage media and non-transitorymachine-readable or computer-readable communication media. Thus, thestorage device of a given electronic device typically stores code and/ordata for execution on the set of one or more processors of thatelectronic device. Of course, one or more parts of an embodiment of theinvention may be implemented using different combinations of software,firmware, and/or hardware.

It is to be understood that the above description is intended to beillustrative and not restrictive. Many other embodiments will beapparent to those of skill in the art upon reading and understanding theabove description. The scope of the invention should, therefore, bedetermined with reference to the appended claims, along with the fullscope of equivalents to which such claims are entitled.

What is claimed is:
 1. A system for managing wireless devices in awireless network comprising: a processor; and a memory coupled with theprocessor, wherein the memory is configured to provide the processorwith instructions which when executed cause the processor to: receive adiagnostic request to analyze a problem associated with a wirelessdevice operating in the wireless network; retrieve contextualinformation associated with the wireless device from a database of thewireless network; determine at least one solution for the problemassociated with the wireless device based on the contextual information;transmit the at least one solution; and receive a confirmation that theproblem has been resolved.